Building embedded languages and expert system shells in Prolog

This paper concerns building embedded languages in Prolog, with special attention on expert system shells. First, the paradigm of meta-programming, of which building embedded languages is an example, is discussed. Second, we review interpreters for embed­ ded languages, concentrating on meta-interpreters. Fi­ nally, two applications, explanation and uncertainty reasoning, are presented and the techniques that were used in their construction are discussed. 1 The Paradigm of Met a-Programming Prolog is widely recognized as a good language for writing simple rule-based expert systems. There are two major factors. First, the primary language con­ structs, Horn clauses, are essentially rules. Second, Prolog's built-in backward chaining interpreter can be used as the inference engine. However, writing rule­ based systems directly in Prolog has limitations due to the 'hard wiring' of both a particular type of repre­ sentation and a particular inference strategy. Further, the language does not provide certain functionalities of an expert system shell, such as tools for interacting with the user, explanation, knowledge acquisition and debugging. Three different approaches have been suggested to overcome Prolog's limitations for building expert sys­ tems [11]. The first method is to build the desired ex­ tensions within the underlying Prolog engine at the im­ plementation level of a Prolog compiler or interpreter. The second method is to translate a knowledge-based system written in a special language to Prolog by us­ ing a special compiler. The third method is to exploit the meta-programming facilities of Prolog. Clearly the first method is the most efficient yet the most inflex­ ible. Developing the desired extensions within Prolog is the easiest method and the most flexible one, since it is not necessary to change the underlying Prolog sys­ tem. In this paper, we advocate this third method and illustrate techniques for building embedded languages and expert system shells in Prolog by exploiting its meta-programming facilities. Let us start by addressing the question "what is meta-programming", a topic which has concerned many researchers. One common definition [2, 19] states CH2915-7/90/0000/0056$01.00 © 1990 IEEE S6 Meta-programming is writing programs that treat other programs as data. By this definition, familiar programs, such as assem­ blers, compilers and program transformers are meta­ programs. Another definition of meta-programming can be ob­ tained by following Hayes-Roth's: Meta-X is a macro definition for 'X about X' [13]. Expanding this macro as in [3], yields another definition of meta-pro­ gramming. Meta-programming is programming about pro­ gramming. Both of the above definitions are descriptive. How­ ever they are missing, in our opinion, the essence of meta-programming by ignoring both the purpose of writing meta-programs and the approach taken for de­ veloping them. We regard meta-programming as a paradigm, which is according to Floyd [12], an approach to writing pro­ grams. A paradigm can also be described as a col­ lection of methods and/or techniques to facilitate the construction of certain classes of programs. Other ex­ amples of paradigms are structured programming, dy­ namic programming, divide-and-conquer and object­ oriented programming. We offer a single sentence definition of the paradigm of meta-programming. Meta-programming is building an abstraction of an object language and developing an in­ terpreter for the abstraction. This definition does not contradict the previous def­ initions. However, it focuses on the purpose behind meta-programming activity. The reason for conceiving a programming task as meta-programming is to clar­ ify and simplify the programming by giving a useful language to the user with which to build applications. In the chapter on meta-linguistic abstractions in their well-known textbook, Abelson and Sussman [1] stress the importance of establishing new descriptive lan­ guages for programming. Tools and techniques are needed both to formulate new languages and to im­ plement these languages by constructing evaluators. From an engineering point of view, it is much simpler to build within a high level language by delegating some of the work, i.e. matching, unification, or back­ ward chaining to the underlying system. Meta-programming is an important paradigm for AI applications. The best way to develop a new applica­ tion, in our experience, is to design a new language tailored to the application. This is only practical if it is easy to design and implement the language. A particular language, such as Prolog, supports meta­ programming by making it easy to write interpreters for a specific application. Interpreters are used for two related reasons for modelling computations. The first one is the execution of an embedded language within a programming language. The next section gives an example of developing an embedded language within Prolog, and gives a simple interpreter. The second reason for developing interpreters is to model a particular inference, such as backward chain­ ing. The interpreter can then be used to develop ex­ pert system shells. In section 3, we discuss how to develop interpreters, classify the purposes of building them and present relevant techniques. In section 4, we discuss two expert system shells, for uncertainty reasoning and explanation, that exemplify the meta­ programming paradigm . 2 Embedded Languages This section gives an example of designing an embed­ ded language for an expert system application. Before giving the details of the example, it is necessary to define some terminology. The domain language is the language used to repre­ sent knowledge about the problem domain. An object language is a language describing a system or applica­ tion program. A meta-language is a language which represents the constructs of an object language explic­ itly. In this paper, we identify the domain and object languages and refer to the two synonomously. Consider writing an expert system to evaluate grad­ uate student applications to a department in a univer­ sity. Such a system must weigh attributes of a student such as GRE scores, grades, recommendation letters, and senior project topic, and classify the student ap­ plication into categories such as accept, reject or con­ sider further. We assume that the attributes can be described qualitatively, such as gre scores are excellent, recommendation letters are very good, and grades are poor. Further, the qualitative terms are assumed to lie on an ordinal scale, poor is worse than good is worse than very good, etc. A discussion on qualitative rea­ soning with attributes from ordinal scales is in [5]. Our system will evaluate students by trying to write down heuristic rules expressed in these qualitative terms, such as "The student should be accepted if her gre scores are excellent, the grades are very good (or better) and the recommendation letters are good (or better)." To build such a system we need a syntax for ex­ pressing rules. Borrowing from Prolog syntax, and taking advantage of the ability to define operators, one is lead to rules of the form Conditions ==> Action, where Conditions are a conjunction, denoted &, or died unction, denoted V, of a set of goals of the form (Attribute, R.elOp, Value). Five sample rules for evaluating graduate students are given. S7 (gre,=,excellent) t (grades,>=,very_good) t (recommendations,>=,very_good)==>accept. (faculty-decision,>,good) ==>accept. (gre,=,excellent) t (grades,>=,good) t {(senior�roject,>=,interesting) V (recommendation,>=,very_good))==>consider. (gre,>=,very_good) t (grades,=,excellent) t (senior�roject,>=,interesting) t (recommendation,=,excellent) ==> consider. (gre,<,excellent) t (grades,<,good) ==> refuse. An interpreter is needed to evaluate whether a cer­ tain Student satisfies the requirements written in the rule language. Such an interpreter, is given below by the predicate evaluate(Student, Decision). It tries the rules in turn until one is found which is appli­ cable for the given student, essentially using a generate­ and-test strategy. By having the representation built on Prolog, two of its features are exploited to eval­ uate the rules. Firstly, these rules are retrieved by using Prolog's built-in backward chaining interpreter. Secondly, the instantiation of variables is achieved by using Prolog's unification. evaluate(Student, Decision) � Qualifications ==> Decision, holds(Qualifications, Student). holds((C1VC2), Student) � holds(C1, Student). holds((C1VC2), Student) � holds(C2, Student). holds((C1tC2), Student) � holds(C1, Student), holds(C2, Student). holds((Concept, R.elOp, ExpVal), Student) � lookup(Concept, Student, Value), values(Concept, Values), compare(R.elOp, ExpVal, Value, Values). The holds predicate tests that all the Qualifications on the left-hand side of a rule hold with respect to the Student under consideration. It depends on compare/4, which compares the Student's Value with the expected value, ExpVal, of the Concept based on the operator R.elOp defined in the rule. Code for compare can be found in [19]. Let us generalize the experience. An embedded lan­ guage for an application is built by • identifying the underlying abstraction necesssary for the task. • defining its representation in Prolog by creating language constructs, such as a new representation scheme for rules. • building an appropriate interpreter for the lan­ guage. The embedded language is more convenient for build­ ing expert systems. The knowledge engineer has the possibility of communicating more directly with the expert and reducing the gap between expert knowl­ edge and expert system knowledge. The user does not need to know the full details of Prolog syntax a.nd ex­ ecution, but can focus on the embedded language. It is possible to build applications directly in Prolog. A sample rule from our running example follows. evaluate(Student, accept) � holds((gre, = , excellent), Student), holds((grades, >=, very_good), Student), holds((recommendation, >= , very_good),